docs: describe rule-based accounts in sandbox - #892
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub. 2 Skipped Deployments
|
|
Warning This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
This stack of pull requests is managed by Graphite. Learn more about stacking. |
✱ Stainless preview builds for gridThis PR will update the cli go kotlin openapi php python ruby typescript Edit this comment to update them. They will appear in their respective SDK's changelogs. ✅ grid-typescript studio · code · diff
✅ grid-openapi studio · code · diff
✅ grid-ruby studio · code · diff
✅ grid-kotlin studio · code · diff
✅ grid-go studio · code · diff
✅ grid-python studio · code · diff
✅ grid-php studio · code · diff
✅ grid-cli studio · code · diff
This comment is auto-generated by GitHub Actions and is automatically kept up to date as you push. |
Greptile SummaryThis PR expands the OpenAPI descriptions for creating and funding rule-based accounts in sandbox.
Confidence Score: 4/5The PR should not merge until the below-minimum guidance identifies the customer’s canonical account, rather than the payer, as the destination of the funds. The new text contradicts the sweep failure schema and BELOW_MINIMUM webhook example, which consistently describe MOVED_TO_CANONICAL_ACCOUNT and expose canonicalAccountId. Files Needing Attention: openapi/paths/sandbox/sandbox_internal_accounts_{accountId}_fund.yaml, openapi.yaml, mintlify/openapi.yaml
|
| Filename | Overview |
|---|---|
| openapi/paths/internal_accounts.yaml | Adds sandbox-specific creation and funding guidance consistent with the generated bundles. |
| openapi/paths/sandbox/sandbox_internal_accounts_{accountId}_fund.yaml | Documents rule-based sweep behavior but incorrectly says below-minimum funds return to the payer instead of moving to the customer’s canonical account. |
| openapi.yaml | Correctly mirrors the source descriptions, including the inaccurate below-minimum destination. |
| mintlify/openapi.yaml | Correctly mirrors the generated contract but publishes the same inaccurate below-minimum destination. |
Prompt To Fix All With AI
### Issue 1
openapi/paths/sandbox/sandbox_internal_accounts_{accountId}_fund.yaml:17-19
**Below-minimum destination is incorrect**
When an integrator rehearses the `BELOW_MINIMUM` path, this text says the funds return to the payer, but the sweep contract moves them to the customer’s same-currency canonical account using `MOVED_TO_CANONICAL_ACCOUNT` and `canonicalAccountId`, causing the integration to expect a refund state or event that is never produced.
---
For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.Reviews (1): Last reviewed commit: "docs: describe rule-based accounts in sa..." | Re-trigger Greptile
0c1fe9f to
577bb9e
Compare
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
5c2e76e to
ddde7a1
Compare
|
⚡ Revision log — updated in place, latest first. Revision 1
|
|
⚡ Review ledger Round 1
|
fe83269 to
5db9bcf
Compare
c639967 to
a55f42b
Compare
29bb0c4 to
3cc5c66
Compare
Sandbox needs no new paths: creation reuses POST /internal-accounts and a settled deposit is stood in for by the existing sandbox fund endpoint. What it does need is saying which half is real, so an integrator knows what a green sandbox run has actually proved. Funding a rule-based account triggers its sweep, and funding outside the corridor band rehearses the path that moves the balance to the customer's canonical account and fires SWEEP.FAILED -- the behaviour most worth exercising before going live, since the rule-based account is left at zero either way. The quote, bounds, destination checks and webhook are real; the settlement legs behind them are not.
3cc5c66 to
16fa863
Compare
2 participants
Summary
Documents rule-based accounts in sandbox. Stacked on #835, which adds the endpoint and the sweep schemas.
No new paths, and no schema changes. Sandbox reuses the same surface: creation goes through
POST /internal-accounts, andPOST /sandbox/internal-accounts/{accountId}/fundalready exists to stand in for a settled deposit. What was missing is a statement of which half of the flow is real, so an integrator knows what a green sandbox run has actually proved.What changed
Two description blocks, +18 lines total:
POST /internal-accounts— notes that sandbox platforms can create rule-based accounts, that the account number is generated locally rather than issued by a partner bank, and that funding via the sandbox endpoint stands in for a deposit.POST /sandbox/internal-accounts/{accountId}/fund— a "Funding a rule-based account" section: funding triggers the sweep exactly as a settled deposit does, and funding below the corridor minimum rehearses theBELOW_MINIMUMpath that returns the deposit and deliversSWEEP.FAILED.That second one is the point of the change. Below-minimum is the behaviour an integrator is most likely to hit without meaning to, and the one whose consequence — the deposit going back to the payer rather than onward — is least guessable from the happy path.
Edited at source, not in the bundle
openapi.yamlandmintlify/openapi.yamlare bundler output —make buildregenerates them from theopenapi/directory. The two description blocks therefore live in their source files:openapi/paths/sandbox/sandbox_internal_accounts_{accountId}_fund.yamlopenapi/paths/internal_accounts.yamlwith both bundles rebuilt. An earlier revision of this PR edited the bundle directly, which would have been silently reverted by the next
make build— worth knowing if you review the diff and wonder why three files carry the same prose.The boundary this draws
This is a deliberate boundary rather than a shortfall. The alternative — registering real partner-bank entities for fictional sandbox customers — is precisely what the platform eligibility rules exist to prevent. Everything above the rails genuinely runs: the same rule lookup, balance read, corridor bounds, destination and rail validation, quote path and webhook that production uses.
Original PR: #889